home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 65 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.3 KB
  1. From: clamage@Eng.Sun.COM (Steve Clamage)
  2. Message-ID: <4djrn4$js1@engnews1.Eng.Sun.COM>
  3. X-Original-Date: 17 Jan 1996 22:03:16 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 18 Jan 96 02:38:07 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: auto_ptr again
  9. Organization: Sun Microsystems Inc.
  10. References: <ADxYD_mKQD@qsar.chem.msu.su>
  11. Reply-To: clamage@Eng.Sun.COM
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMP2yoOEDnX0m9pzZAQEDKAF/RF1SKyPbQ9Irf7/ge6bzU+C6ELbYfoZf
  14.     sblFZzIp287SARecH29v+aF7ueRTNztF
  15.     =PIcf
  16.  
  17. In article mKQD@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su>
  18. writes:
  19. >Hi!
  20. >I would like to suggest returning to the definition of auto_ptr. The fact
  21. >is, in current form it is almost unusable for most things due to its
  22. >underlining concept of a single strict ownership. Actually, we need
  23. >multiple-instance auto_ptr. If, as I suspect, its inclusion was prevented
  24. >by the problem of efficiently allocating the counter in ref.counted
  25. >pointer, then we could parameterize auto_ptr WRT not only the type, but
  26. >allocator as well. Also, we could use doubly-linked list instead. And
  27. >anyway, it is the implementation problem!
  28.  
  29. That point has been beaten to death in the C++ committee and also in
  30. this forum. Some people felt an auto_ptr should be able to have multiple
  31. owners, but people with experience with this kind of design persuaded
  32. the committee that auto_ptrs are too hard to use unless they can have
  33. only a single owner. Thus, ownership is transferred upon copying.
  34.  
  35. That is, single ownership is a deliberate design decision based on the
  36. semantics an auto-ptr should have. It is not an implementation issue.
  37.  
  38. Unless someone can present new evidence that shows the arguments in favor
  39. of single ownership are wrong, and in addition shows that multiple
  40. ownership is always better, this subject won't be reopened in the committee.
  41.  
  42. (Yes, examples are known where multiple ownership does what you want.
  43. That doesn't mean it is overall the best design. And nothing prevents
  44. you from writing your own multiple-owner class.)
  45.  
  46. ---
  47. Steve Clamage, stephen.clamage@eng.sun.com
  48. ---
  49. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  50.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  51.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  52.